Light ROM 4/Light ROM 4 - Disc 1.iso/text/maillist/1994/aug94.doc/000471_owner-lightwave-l _Tue Aug 23 07:32:09 1994.msg

Internet Message Format | 1995-03-23 | 4KB

Return-Path: <owner-lightwave-l>
Received: by mail2.netcom.com (8.6.9/Netcom)     id GAA13692; Tue, 23 Aug 1994 06:57:50 -0700
Received: from corsa.ucr.edu by mail2.netcom.com (8.6.9/Netcom)     id GAA13685; Tue, 23 Aug 1994 06:57:48 -0700
Received: (from jcsky@localhost) by corsa.ucr.edu (8.6.9/8.6.9) id GAA27169 for [e-mail]; Tue, 23 Aug 1994 06:57:12 -0700
From: joe solinsky <[e-mail]>
Message-Id: <[e-mail]>
Subject: Re: Particle effectuators
To: [e-mail]
Date: Tue, 23 Aug 1994 06:57:12 -0700 (PDT)
In-Reply-To: <[e-mail]> from "[e-mail]" at Aug 22, 94 11:22:53 pm
X-Mailer: ELM [version 2.4 PL23]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 3104
Sender: [e-mail]
Precedence: bulk
Reply-To: [e-mail]

>     Would there be any merit to having "magnets" and "repulsars" in
> LAYOUT?  These would be points that have a displacement effect on
> object geometry.

I like it, how about everyone else?
A noteworthy feature (just a toggle for the user, but a different programming
attack) would be to switch between deforming the object, or keeping it rigid.
More to the point, level settings would also be sage.  A use for keeping the
body rigid or semi rigid would be to introduce a "collision" effect that
even though would not be full physics collision detecting (like what is in real
3D), but would at least provide a built-in manner for the artist to mimic such
behaviour.  I think the physics are clear on this algorithm already, but if
anyone wants it, I can attempt to write it up.  Gotta do something with that
$75. text book I still have...

>
>     By having "magnets" treated as a particle cloud, for instance, we
                         ^^^^^^^^
I like clouds!

>     Effect only happens to polys whose normals are within X amount of
>     a given vector--and inverse.
>
>     Effect only happens to specific polys, i.e. polys with a given
>     surface name (multiple names).

That second line about defining affected polygons seems... tedious.
Being kinda new to the toaster (but not 3D), may I ask if objects can have
multiple surfaces?  Having poured over the notes on the format of the object,
I would say no. Am I correct?
If this is so, you would find yourself seriously redefining pre-existing
objects to be compatible with this feature.  What I think might be a better
technique would be to employ whatever picking (gosh, is that an imagine term?)
methoods fit the user's fancy, then if you wanted to treat it as a surface, force
the user to save the object as a new file, and with that new save, create the
redefined surfaces.  This way, the artist would not have to model with the
magnet and repulser forces in mind.

With the first line, within the radius X, the effect should be able to occur in
a linear fashion (everything affected within the sphere at the same rate) or
using the ol' distance formula 1/x^2 .  Depending on how enthusiastic your
programmers are, see if they are willing to support multiple geometries for
the radius of influence (gosh, is that another Imagine term? shame on me!),
such as a rectangular prism as opposed to just a sphere.

Of course,the problem with all these cool features is the learning curve and
the documentation.  Although it is an odd approach, write the documentation
before the algorithm.  Try to come up with a metaphor for what your algorithm
does.  Apply it to a real world concept (or multiple ones).  Say it is like a
magnet, but go into it.  If you think about it, your documentation is the only
chance you will have to prep the user on your tools.  While they are reading,
if what you write is easy to understand, inventive, and clear, the user should
hopefully be inventing ideas and planning the use of these tools during the
process of understanding it all.

-Joe Solinsky (who writes really long messages for someone who should be doing
his math homework)